Roads, railroads, runways and taxiways, open channels, including restored streams, culverts, tunnels, and underground utilities are all generally referred to as “corridors.” Although roadways are often discussed herein, any discussion related to roadways applies equally to any other type of corridor. Indeed, these corridors are controlled by Horizontal Alignments and Vertical Alignments. Horizontal Alignments serve as curvilinear auxiliary coordinate systems and consist of line segments, circular arcs, and portions of Euler Spirals. These elements are chained together in the Coordinate Geometry Database (also known as the Cogo Database) to make up the Horizontal Alignment (HA). The resulting HA serves as the axis about which all roadway or corridor elements are located in the Horizontal Plane.
When a Vertical Alignment, also known as a Profile or Grade, is associated with a Horizontal Alignment, this combination defines a three-dimensional reference curve about which all other aspects of a corridor are established. Storing, manipulating, and referencing these alignments is an essential prerequisite to developing a roadway model.
However, a Horizontal and Vertical Alignment combination is not sufficient to define all aspects of a proposed roadway. Widths and cross slopes of the roadway surface, shoulders, curbing, ditches, and side slopes are also inherent to the model. Historically, these components have been modeled via cross sections, which are slices of the proposed roadway taken every fifty feet or so. They may be considered equivalent to a variable-orientation Front View, usually oriented at a 90 degree skew to the Horizontal Alignment. In other words, the View Z axis is constrained to lie in the World XY plane and is parallel to the instantaneous tangent of the Horizontal Alignment.
Known approaches have departed from requiring the user to interact with the roadway model via cross sections because they are fixed at static locations, thus limiting flexibility in the design process. Generating cross sections at a density higher than fifty feet would provide more accuracy, but the labor time involved is generally considered inefficient. Despite this trend, proposed cross section plan sheets are still a primary deliverable requirement for most agencies and probably always will be.
Deliverable outputs of a corridor model include alignment data for use in construction survey, quantity computations, paper or electronic plan sets, machine control data, and visualization and presentation, each of which is addressed below.
When a construction project is undertaken, the designer delivers the alignment data to the surveyor who then stakes essential construction control points of the alignment data for others to build by. Usually the output of the Cogo database to some industry standard interchange format is adequate for this alignment data to be delivered.
When a project is bid on by interested contractors, they generate their construction cost bid based on the projected quantities of various pay items. These quantities are computed by the design engineer or an estimating engineer. Approximately 90% of all quantities are computed directly from the design plans. When a project is complete, final quantities are the basis of payment to the builder (or contractor). If final quantities vary too much from estimated quantities, the contractor has grounds to require renegotiation of the unit price of the quantity in variance.
Some of these quantity calculations are simple (such as area of clearing and grubbing), but some are much more complex requiring many hours of computation and input from other quantities. An example of a complex computation is tons of Asphalt Cement for adding to the asphalt plant mix. Volumes of pavement must be computed precisely. Different pavement courses have different mix recipes. Once volumes are known, they are converted to tons per course, which then are used to compute Asphalt Cement, but based on differing rates for different pavement courses.
A well-planned quantity computing application that is closely integrated with the roadway model would be attractive to potential customers if it can save them time in computation and summarizing while leaving a human-readable computation record for project design documentation.
We still build roads by looking at drawings on pieces of paper. Although electronic automation will continue to grow in importance, we will always need plots. Paper and electronic plansets are essential for the engineer to deliver his or her final product to the client.
Much construction activity has become computer controlled with the construction machine driver taking control of the machine only occasionally. The machine control data that is utilized by these packages has become a part of final project delivery which may no longer be overlooked. Fortunately the format is in a well-defined XML protocol. The software simply exports the roadway model which has been developed by the design engineer to the XML file.
Not all consumers of the engineers' work product know how to read roadway plans. For this reason, a small but significant portion of the work of engineers and consultants is in the generation of presentations of the project which are more easily understood by the public. CAD packages must enable accurate and user-friendly development of presentation files directly from the survey data and the proposed roadway model.
The current leaders in the roadway design software market are all moving to a template-based approach with heavy reliance on abstract concepts which are oriented towards a software developer's view of the world and not an engineer's. This leads to non-intuitive user interfaces and cumbersome work flows resulting in models which are still represented by triangulated (irregular) point networks (TINs). Reducing the design surface to a TIN eliminates the original designer's intentions and decisions, and is not amenable to translating back to the design model, all of which are undesirable.